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HANDLING  EXCEPTIONAL  CONDITIONS  IN  PSN 


Xves  Lesperance 


Department  of  Computer  Science 
University  cf  Toronto 
Toronto,  Canada 
M5S  1 A  7 


AESTEACT 


This  paper  describes  a  scheme  for  handling  both  exceptional 
objects  and  classes  and  exceptional  conditions  that  arise  in  the 
execution  of  programs,  within  a  knowledge  representation 
formalism.  The  scheme  consists  of  two  mechanisms:  the  excuse, 
which  allows  the  justification  of  specified  constraint  violations 
in  instances  of  a  class  through  membership  in  a  second  class 
within  designated  contexts,  and  the  mapping,  which  permits  the 
specification  of  similarity  relationships  between  the  definitions 
of  two  objects,  sc  that  arbitrary  elements  of  these  definitions 
may  he  copied  or  inherited  (a  flexible  IS-A) .  Exceptions  in 
programs  are  handled  through  an  extension  of  the  excuse 
liecha  nism . 
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1.0  INTRODUCTION 


In  order  to  perforin  intelligently  ,  a  system  must  possess  a 
model  of  its  world  and  le  able  to  use  it  to  deal  with  the  often 
unexpected  situations  that  arise.  The  knowledge  in  this  model 
[knowledge  base)  is  organised  in  terms  of  a  system  of  cat egor ies . 
The  categories  may  be  explicit,  as  in  frame  systems  [Minsky  74], 
cr  more  implicit  as  in  logical  formalisms.  Exceptions  in 
representation  systems  arise  as  a  result  of  (1)  the  sometimes 
unpredictable  nature  of  the  world,  which  produces  atypical 
situations,  and  (2)  the  inadequacies  of  current  representation 
formalisms  in  dealing  with  "natural"  concepts  (as  used  by 
people) .  These  exceptions  manifest  themselves  through  the 
violation  of  some  constraints  during  the  lifetime  of  the 
knowledge  base. 


A  simple  classification  of  exceptional  conditions  will  help 
in  finding  ways  to  deal  with  them.  Generic  exceptions  can  first 
be  distinguished  fron  individual  exceptions,  as  the  former 
pertains  to  constraints  violated  in  the  definition  of  a  category 
rather  than  in  particular  individual  objects.  Individual 
exceptions  can  be  further  subdivided  into  static  exceptions, 
which  arise  while  the  systems  is  attempting  to  instantiate  or 
recognize  an  object  (basic  operations  at  the  top-level) ,  and 
dynamic  exceptions,  which  are  encountered  during  the  execution  of 
a  user  defined  program. 


This  paper  sumarizes  an  exception  handling  system  develloped 
for  the  PSN  representation  formalism  [ levesgue  79],  which  is 
explained  in  details  in  [lesperance  80].  The  seminal  ideas  for 
the  system  came  from  [Minsky  74],  where  two  ways  of  recovering 
from  failure  in  a  frame  system  were  suggested.  First,  it  may  try 
to  create  an  excuse  for  the  exceptional  condition  with  an 
appropriate  reason.  In  this  approach,  the  failure  is  seen  as 
arising  from  the  fact  that  the  defective  object  is  really  an 
instance  of  two  frames  which  interact,  thus  the  object  does  not 
satisfy  perfectly  the  ideal  defined  in  one  of  the  frames.  The 
knowledge  necessary  to  make  the  repair  should  be  attached  to  a 
higher  thematic  context  frame.  The  second  approach  involves 
using  the  local  advice  embedded  in  a  similarity  network  to 
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replace  the  defective  frame  by  a  more  appropriate  one. 

The  two  approaches  reflect  the  distinction  between 
individual  and  generic  exceptions.  In  the  first  case,  we  do  not 
wish  to  create  new  categories  for  eyery  single  exception,  thus  an 
excuse  mechanism  has  been  devised  to  allow  the  handling  of  both 
static  and  dynamic  exceptions  and  the  maintenance  of  the 
consistency  of  the  knowledge  base.  The  excuse  mechanism  has  been 
influenced  extensively  by  exception  handling  mechanisms 
devellcped  for  programming  languages,  [Levin  77]  in  particular. 
These  mechanisms  allow  the  mainline  of  the  program  to  be 
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The  PSN  formalism  grew  out  of  a  desire  to  develop  a  facility 
for  defining  semantic  network  knowledge  bases  with  well  defined 
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behavior  of  the  class  under  the  operations  of  instantiation, 
removal  of  an  instance,  testing  for  membership  and  fetching  of 
all  instances.  Classes  are  represented  graphicaly  by  their 
external  name  in  capitals,  for  example  "HUMAN"  or 
"EXCEPTION-CLASS"  in  figure  1.  Whenever  an  individual  object  is 
made  an  insta nee  of  a  class,  the  appropriate  attached  program  is 
executed,  this  allowing  the  desired  inferences  (antecedent 
theorems)  to  be  added  to  the  knowledge  base.  Similar  action  is 
taken  in  the  case  of  the  three  other  operations.  Simple  token 
objects  are  represented  in  the  graphic  notation  by  their  external 
name  in  lower  case,  for  example  "Capt ' n- Kid d "  in  figure  1.  The 
INSTANCE  assertion  is  represented  by  an  unlalled  single  line 
arrow.  Incidental  relationships  between  objects  (the  links  in 
traditional  semantic  networks)  are  represented  by  a  class  of 
objects  called  relations ,  whose  semantics  are  also  defined  by 
four  programs.  The  instances  of  relations  are  assertions  of  the 
relationship  between  two  specific  objects. 

This  basic  procedural  PSN  is  augmented  with  declarative 
facilities  which  help  in  the  organization  of  the  knowledge  base. 
The  defining  properties  of  a  class  are  grouped  together  to  form 
the  structure  of  the  class,  which  consists  of  a  set  of  slots 
which  can  have  a  type,  restrictions,  default,  etc.  The  structure 
of  a  class  is  represented  by  a  box  under  the  name  of  the  class, 
for  example  "HUMAN"  in  figure  1,  and  slots  by  their  name  with  a 
node  written  in  the  box,  for  example  "legl" .  These  slots  can 
then  be  filled  with  values  when  an  instance  of  the  class  has  been 
created.  This  is  represented  by  a  link  labelled  with  the  name  of 
the  slot  as  for  the  "legl"  of  "Ca pt * n-Kidd"  is  " wooden-le g- 1"  in 
figure  1 .  The  closure  of  these  structural  property  value 
relationships  forms  the  PAET-OF  hierarchy.  The  classes  can  also 
be  organized  in  an  IS-A  cr  specialization  hierarchy  (represented 
by  unlabled  double  line  arrows,  see  figure  2) .  This  facilitates 
the  definition  of  the  subclasses  as  the  structure  of  the 
superclass  is  inherited  by  them.  The  slots  can  be  refined  but 


are  reguired  to  satisfy  the  IS-A  constraints,  which  guarantee 
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that  the  subclasses  are  effectively  specializations. 


Slot 


values,  in  particular  the  four  programs  defining  the  semantics  of 
classes,  can  also  be  inherited  if  necessary. 

The  instance  hierarchy  is  not  restricted  to  two  levels  and 
classes  cah  be  instances  of  setaclasses.  This  is  used 
extensively  in  the  definition  of  the  formalism  itself  and  many 
aspects  of  its  behavior  arise  as  a  result  of  the  definition  of 
the  metaclasses:  CLASS,  P  ELAT  10  N,  OBJECT,  P  EOGP  AM ,  etc.  A 

metaclass  can  constrain  the  structure  of  its  instances  through 
its  metastructure  [Kramer  <30  ],  as  the  slots  of  the  instance  must 
be  instances  of  the  metaslots  in  the  metastructure.  Programs  are 
represented  as  classes  in  the  formalism,  and  thus  benefit  from 
all  the  declarative  facilities.  In  figure  2,  the  program 
"ARRANGE- TRIP"  calls  another  program  "RESERVE-SEAT".  Metaslots 
have  been  used  to  partition  the  slots  into  different  categories: 
parameters,  locals,  etc.  To  specify  the  desired  parameter 
bindings  and  evaluations,  a  form  is  used  [the  box  with  no  heading 
under  "RESERVE-SEAT").  The  programs  are  executed  by  creating 
processes  which  are  instances  of  the  programs,  "arrange-tri p- 1" 
and  "reserve-seat- 1"  in  the  example 
a  context  mechanism  [ Schneider 
which  is  visible  in  a  context  is  called  a  view.  Context  are  used 
tc  implement  inheritance,  structures  being  essentialy  special 
forms  of  contexts.  A  slot  is  inherited  because  it  is  visible  [a 
view)  in  the  structure  of  subclasses. 


The  formalism  also  provides 
78,  Schneider  80].  An  object 


The  only  differences  with  some  previous  versions  of  PSN  are 
the  use  of  valuers  to  implement  manifestations  (ex:  John  as  a 
taxpayer)  as  in  [Schneider  78],  which  are  needed  for  the  proper 
treatment  of  dynamic  exceptions,  and  the  ability  to  refer  to  most 
systems  assertions  (INSTANCE,  type,  etc.).  This  feature  can  be 
simulated  without  any  extension  to  PSN  by  replacing  the  single 
link  assertion  reference  by  a  triple  link  reference  to  the 
relation  and  its  arguments. 
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3.0  EXCUSES 

3.1  STATIC  EXCEPTIONS 

The  excuse  mechanism  takes  care  of  objects  which  are 
instances  of  a  class  while  violating  seme  of  the  constraints 
associated  to  its  slots.  The  exceptions  which  are  raised  by 
these  violations  must  be  handled  by  the  class  of  the  object  which 
has  the  defective  object  as  one  of  its  parts  (slot  value),  thus 
cne  level  up  on  the  PART-CF  hierarchy.  This  provides  a  basic 
form  of  context  sensitivity  to  the  mechanism.  The  handler 
attached  to  the  "situation"  is  restricted  to  being  a  class  of 
which  the  defective  object  must  also  be  an  instance,  thus 
retaining  Minsky* s  idea  of  frame  interaction  in  a  context. 

let's  explore  the  mechanism  in  more  detail  by  considering  an 
example  of  static  exception  handling  represented  graphicaly  in 
figure  1.  Here,  we  have  an  object  "Capt 'n-Kidd" ,  which  would  be 
a  legal  instance  of  the  class  "HUMAN",  except  for  the  fact  that 
the  value  of  its  slot  "leg-1",  " wooden-leg- 1 " ,  violates  the  type 
constraint  of  the  "leg-1"  slot  definition  in  the  class  "HUMAN". 
The  violation  is  precisely  that  "wooden-leg-1"  is  not  an  instance 
of  "HUMAN-LEG".  To  characterize  this  type  of  constraint 
violation,  an  exception-class  called  "NO-EEAL-LEG"  is  created. 
Then  this  class  is  associated  to  the  type  of  the  slot  "leg-1" 
using  an  except ion- link.  When  the  system,  attempting  to  fill  the 
value  of  "leg-1"  for  "Capt * n-Kidd"  will  detect  the  type 
violation,  it  will  find  the  exception-link  and  then,  if  the 
predicate  of  the  link  is  satisfied,  it  will  create  an  instance  of 
the  exception  class  "NO-REAL-1EG"  .  The  exception  "no-real-leg-1" 
is  attached  to  the  INSTANCE  link  between  "Capt 'n-Kidd"  and 
"HUMAN",  which  thus  becomes  an  EXCEPTIONAL-INSTANCE  link.  This 
is  done  by  making  the  exception  an  instance  of  an  exception-class 
created  especialy  for  the  link.  Many  exceptions  could  be  raised 
cn  the  instance  in  the  same  way. 

The  rest  of  the  mechanism  concerns  the  handling  of  the 
exception,  where  the  system  tries  to  build  an  excuse  for  the 
exception.  For  that,  it  climbs  up  one  level  in  the  PART-OF 
hierarchy  and  looks  at  the  corresponding  class  to  find  an 
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excuse-class.  In  the  example,  this  corresponds  to  following  the 
"main-charact  er"  assertion  to  "story-1",  then  looking  at  its 
class  "PI  SATE- STOEY"  and  then  finding  "EXCUSE-CLASS-1 " .  This 
excuse-class  must  have  heen  attached  to  the  slot  whose  value  is 
the  exceptional  instance.  For  the  excuse-class  to  be  usable,  it 
must  be  associated  to  the  exception-class  of  which  the  exception 
is  an  instance.  If  this  is  the  case,  then  the  system  tries  to 
make  the  exceptional  object  an  instance  of  the  class  which  is  the 
value  of  its  "by"  slot,  which  is  "DIS ABLED-PEESON "  in  this  case. 
Any  desired  checking  for  evidence  for  this  type  of  excuse  can  be 
dene  at  this  stage.  If  the  instantiation  has  been  succesful, 
then  an  excuse  is  created,  which  associates  the  justification  to 
the  exception.  In  the  example,  this  is  "excuse-1".  The  excuse 
marks  the  succesful  handling  cf  the  exception.  If  all  the 
exceptions  attached  to  an  exceptional-instance  link  via  its 
exception-class  have  been  excused,  then  the  link  becomes  an 
EXCUSED— I NSTA NCE  link. 


Exception-classes  in  this  system  have  a  two-fold  function: 
they  are  abstract  descriptions  cf  the  violations  that  arise  and 
they  allow  an  economical  interface  between  the  excuse-classes, 
which  handle  the  violations,  and  the  violations  themselves, 
assuming  that  some  violations  will  be  treated  in  the  same  way. 
The  use  of  the  PABT-QF  hierarchy  as  a  kind  of  context  mechanism 
for  exceptions  is  new  to  PSN,  but  resembles  that  of  NETL  [Eahlman 
79].  The  excuse  mechanism  also  works  nicely  for  cases  of 
nen-existant  slot  values.  In  this  case,  the  special  object 
"nothing"  is  given  as  a  value.  This  can  be  treated  as  a  type 
violation  and  be  handled  in  the  normal  way. 


3.2  DYNAMIC  EXCEPTIONS 

The  excuse  mechanism  can  be  used  to  handle  dynamic 
exceptions  with  a  few  extensions.  It  is  natural  to  see 
exception-classes  as  the  interface  between  the  program  context 
raising  the  exception  and  the  one  which  will  be  selected  to 
handle  it.  As  these  two  belong  to  different  levels  of 
atstraction,  it  is  necessary  tc  provide  parameter  passing 
facilities  with  exceptions.  These  are  defined  as  slots  in  the 
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After  the  creation  of  the  exception,  the  system  looks  fo 
excuse-class  (having  the  appropriate  exce ption-class)  attache 
the  slot  that  was  being  evaluated  in  the  caller  of  the  pro 
that  raised  the  exception.  The  dynamic  hierarchy  is  used  ins 
of  PAET-OE  as  it  fills  a  similar  role  in  dynamic  objects 
programs  to  that  of  part-of  in  static  objects.  Thus 
’•dynamic"  assertion  is  followed  from  "reserve-seat-1" 
"a rra nge- trip- 1" ,  where  the  "  EXC U SE-C LA SS- 1  "  is  located,  from 
"reservation"  slot  that  was  being  evaluated.  Then,  the 
which  is  the  value  of  the  "by"  slot  and  a  subclass  of 
" EIND-ALTEENATIVE "  program  is  instantiated  (executed),  as 
exception  handler.  Here  again,  a  form  is  used  to  allow  for 
binding  of  parameters.  The  instance  of  the  "by"  c 
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assignements  to  the  slots)  makes  the  separation  of  the  two 
manifestations  clear.  The  exception  handling  process  thus 
appears  as  a  tailoring  of  the  process  "reserve-seat- 1 "  to  fit  the 
particular  situation  at  hand.  Once  the  instantiation  has 
completed,  an  excuse  is  created  ("excuse- 1")  for  the  succesfuly 
handled  exception.  Then,  the  "result"  of  the  handler,  that  is 
the  value  of  its  slot  which  is  an  instance  of  the  "returns" 
metaslot,  can  be  passed  back  to  the  exception  and  to  the  process 
which  raised  it.  This  amounts  in  this  case  to  set  the  local  slot 
"substitute"  to  this  value.  Then,  the  process  resumes  after  the 
point  of  interuption.  A  process  can  trigger  an  exception 
voluntarily  by  returning  the  special  value  "fail"  in  the  same  way 
as  "nothing"  in  the  static  case. 

3.3  INTERACTION  S  WITH  THE  HIERARCHIES  AND  SEMANTICS 

The  immediate  father  in  the  PART-OF  (dynamic)  hierarchy  is 
not  always  the  best  class  to  provide  an  excuse  for  an  exception, 
but  the  scheme  requires  the  exception  to  be  reformulated  in  terms 
of  the  father  class  before  it  can  be  passed  up  higher,  so  as  to 
preserve  the  abstraction  structure.  This  is  done  in  the  static 
case  by  considering  the  unexcused  exceptional  object  as  violating 
the  type  cf  the  father.  In  the  dynamic  case,  the  handler  ("by" 
class)  can  also  raise  a  new  exception  of  its  own,  as  it  is 
treated  as  a  part  of  the  caller's  context. 

Even  if  it  does  not  appears  so  by  the  examples  given,  it  is 
intended  that  except ion- links  and  excuse-classes  be  inherited 
with  the  slot  they  are  attached  to  down  the  IS-A  hierarchy.  They 
can  also  be  refined  and  have  to  satisfy  the  IS-A  constraints 
(that  their  parts  be  identical  or  IS-A,  including  the 
exception-class  and  the  "by"  class) .  This  can  be  enforced  by  the 
formalism  if  these  objects  are  defined  as  classes  with  slots 
representing  the  links,  as  in  [Kramer  80].  However  this  solution 
is  not  totaly  satisfactory.  A  default  exception-class  called 
"GENERAL-EXCEPTION-CLASS"  is  provided  by  the  formalism  to  every 
slot  defined,  through  the  inheritance  mechanism. 
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The  excuse  mechanism  can  be  considered  to  be  simply  a 
syntactic  extension  of  the  original  PSN  formalism.  The 
attachement  of  an  exception-link  and  exception-class  to  a  slot 
can  be  seen  as  the  creation  of  a  class  which  only  differs  from 
the  original  class  by  the  required  presence  of  the  violation 
which  would  raise  the  exception.  The  attachement  of  an 
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inheritance-  The  rest  of  the  presentation  concerns  mainly  the 
structural  aspect  as  the  other  still  needs  to  he  worked  out  in 
details. 

The  main  influences  on  the  mapping  mechanism  have  been  the 
mappings  of  MERLIN  [Moore  73],  where  the  recursive  aspect  of  the 
definition  is  taken,  the  "cables"  of  KLONE  [ Brachman  79],  for  the 
idea  of  structured  inheritance,  and  the  similarity  networks  of 
[ Winston  75 ]. 

The  main  idea  on  which  the  mechanism  is  based  is  that  any 
mapping  cf  an  object  must  also  involve  the  mapping  of  its 
type(s) ,  as  it  is  an  essential  part  of  its  definition-  This 
requirement  causes  the  structure  of  mappings  tc  mirror  closely 
that  of  the  INSTANCE  hierarchy.  If  we  return  to  our  example  in 
figure  3,  the  mapping  "P/B-MAP"  between  the  clases  "PENG  DIN"  and 
"EIRD"  is  also  a  class  and  an  instance  of  "CLASS-MAE".  It 
contains  a  slot-mapping  slot,  "beakp/beakb" ,  from  the  "beakp" 
slot  of  "PENGUIN"  to  the  "beakb"  of  "BIRD".  The  type  of  this 
slot,  "PB/BB-MAP",  is  another  mapping  class  from  the  type  of 
"leakp" ,  "PENGUIN-EEAK",  to  the  type  of  "beakb",  " EIR C-BEAK" . 
"PB/BB-MAE"  would  itself  be  expanded  in  the  same  way  to  map  the 
slots  cf  both  classes.  Now  at  the  token  level,  there  is  an 
instance  of  "P/E-MAP",  mapping  "penguin-1"  to  "Tweety".  It  has 
as  slot  value  a  mapping  between  both  "beak"  slot  values,  which  is 
an  instance  of  "PE/BB-MAP".  Thus,  the  mapping  at  the  class  level 
allows  us  to  map  the  instances  of  the  class.  The  structure  of 
the  mappings  is  exactly  parallel  to  that  of  the  classes  mapped. 

However,  to  satisfy  completely  our  requirement,  the  types  of 
the  classes  "PENGUIN"  and  "EIRE"  must  also  be  mapped.  This  is 
accomplished  by  "CLASS/CLASS-MAP",  which  maps  the  class  "CLASS" 
into  itself.  Ncte  that  both  "P/B-MAP"  and  "PB/BB-MAP"  are  also 
instances  of  this  metaclass.  The  type  of  "CLASS"  itself, 
"METACLASS",  would  also  need  to  be  mapped,  but  eventualy  this 
will  stop  as  "METACLASS"  is  only  an  instance  of  itself. 

The  classes  that  define  mappings  ("CLASS-MAP", 
"METACLASS-MAP",  etc.)  also  allow  us  to  create  a  taxonomy  of 
mappings  and  differentiate  between  identity  mappings,  IS-A 
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lappings  ana  general  similarity  mappings.  This  is  done  by 
gradualy  adding  more  constraints  on  the  structure  cf  lappings 
(e.g.  the  "interval"  cf  "CLASS-MAP"),  mainly  on  the  metaslot 
ccntroling  slot  mappings  ("slot-map-slot").  This  produces  a 
pseudo-IS-A  hierarchy  of  mappings.  In  the  example,  the 
"FB/BB-MAP"  is  an  instance  of  "I S-A-CLASS-MAP"  and  its  argument 
classes  would  satisfy  the  IS-A  constraints.  "Cl ASS/C  LASS -M AP "  is 
an  instance  of  "IDENTITY-CLASS-MAP"  as  it  maps  a  class  to  itself. 

The  trapping  construct  allows  the  representation  of 
similarities  of  similarities,  as  mappings  are  simply  objects  like 
everything  else.  It  is  also  a  powerful  tool  to  study 
relationships  involving  the  parts  of  objects  as  well  as  the 
otjects  themselves.  An  interesting  guesticn  raised  by  the 
characterization  of  IS-A  as  a  class  of  mappings  is  whether  its 


set-inclusion  a 
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abstract  comparison 

of 

exis  ting 

structures  should  not  be  confused  with  the  INSTANCE  assertion 
itself,  which  is  the  result  of  an  external  recognition  process 
starting  from  sensory  features  and  whose  existence  is  assumed  by 
the  mapping  mechanism. 

5.0  CCMPAEISCN  TC  GT  HEP  SCHEMES 

The  only  other  representation  formalism  to  give  significant 
attention  to  the  static  and  generic  exception  problems  is  NETL 
[Eahlman  79].  Its  solution  is  much  simpler  than  ours,  being 
lased  on  the  insertion  of  "CANCEL"  links  in  the  virtual  copy 
hierarchy  to  cancel  inheritance  when  needed.  This  may  be 
considered  analogous  to  a  mapping  mechanism  based  on  differences. 
There  is  no  need  for  excuses  as  NETL  neither  does  include  a 
separate  instance  hierarchy  nor  programs.  The  mechanism  is 
defined  at  a  lower  level  cf  abstraction  than  ours  (the  user  is 
ccncerned  with  the  inheritance  process)  and  is  affected  by  the 
emphasis  on  retrieval.  It  does  not  offer  the  descriptive 
facilities  of  our  solution  and  does  not  enforce  any  consistency 
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or  justification  requirement. 


The  excuse  mechanism  for  dynamic  exception  handling  has  many 
points  in  common  with  those  of  [Kramer  80]  and  [Mylopoulos  79]. 
However,  it  differs  essentialy  with  that  of  [Kramer  80]  on  the 
guestion  of  where  control  should  be  returned  after  the  completion 
of  the  exception  handler.  We  reguire  the  resumption  of  the 
process  which  raised  the  exception,  rather  than  return  control  to 
its  caller.  This  makes  it  easier  to  ensure  that  the  model  is  not 
left  in  an  inconsistent  state,  is  more  efficient  and  promotes  a 
more  natural  view  of  abstractions. 

A  more  logical  approach  to  exceptions  has  recently  been 
proposed.  Exceptions  are  seen  as  entities  for  which  some  default 
inference  rule  does  not  held  [Reiter  78](e.g.  birds  fly  unless 
we  can  prove  otherwise,  fer  penguins  the  rule  does  not  hold). 
Systems  based  on  this  principle  maintain  justifications  for  their 
assertions  and  reevaluate  them  as  new  facts  are  learned,  which 
may  contradict  existing  defaults  deductions  [Doyle  79].  If  a 
satisfactory  (non-monotonic)  logic  can  be  found  to  characterize 
these  systems,  it  could  improve  greatly  our  understanding  of  the 
nature  of  exceptions  and  how  to  deal  with  them. 


€.0  CCNCIUSICN 
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Figure  '1  -  Example  of  excuse  for  static  exception 
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Figure  2  -  Exaaple  of  excuse  for  a  dynamic  exception. 
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Abstract 

The  procedural  semantic  network  (PSN)  formalism  for 
representing  knowledge  has  as  a  basic  concept  the  use  of 
programs  to  define  the  semantics  of  classes  of  objects.  This 
paper  investigates  a  means  of  representing  programs  based  on 
work  done  by  the  author  ([Kramer  1979  ],  [Kramer  1980]). 
Included  as  an  important  part  of  representing  programs  is  an 
extension  of  PSN  which  provides  a  means  for  categorizing  the 
properties  of  objects. 

1.  Introduction 


The  representation  of  programs  as  objects  of  the  knowledge 
base  has  always  been  an  important  part  of  the  procedural 
semantic  network  (PSN)  formalism  ([Levesgue  1977  ],  [Levesque 
and  Mylopoulos  1979],  [Schneider  1  978a],  [Schneider  1978b]). 
This  work  has  been  continued  in  the  development  of  the  language 
TAXIS  ([Mylopoulos  et  a  1.  1978  ],  [Wong  1980  ])  which  embodies 

many  of  the  concepts  of  PSN  although  its  emphasis  is  on  the 
design  of  interactive  information  systems  rather  than  knowledge 
bases.  The  behaviour  of  programs  in  TAXIS  is  used  in  [Kramer 
1980]  and  in  this  paper  as  a  new  basis  for  representing 
programs  in  PSN.  The  contributions  of  TAXIS  are  a  new 
mechanism  for  associating  the  statements  of  a  program  with  the 
program  and  a  general  exception  handling  mechanism. 
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The  new  proposals  for  the  treatment  of  programs  in  PSN  are 
discussed  in  more  detail  in  [Kramer  1980].  This  discussion 
includes  some  work  on  the  handling  of  exceptions  in  the  dynamic 
environment  of  programs.  Exception  handling  in  PSN,  however, 
involves  more  than  the  correction  of  such  exceptions.  A 
different  kintl  of  exception  is  that  which  occurs  in  the 
maintenance  of  an  object  in  the  knowledge  base  which  fails  to 
meet  some  re strictions.  For  more  details  on  the  handling  of 
both  kinds  of  exceptions  the  reader  is  referred  to  [Lesperance 
1980  ]. 

2.  Overview  of  PSN 

Programs  enter  into  PSN  as  entities  describing  the 
behaviour  of  classes  and  relations.  Every  object  is  an 
instance  of  a  class;  the  programs  of  the  class  specify  how  an 
object  might  be  made  such  an  instance,  how  an  instance  should 
be  removed  from  the  class,  a  test  for  membership  in  the  class, 
and  a  mechanism  for  fetching  all  instances  of  the  class. 
Binary  relations  are  represented  by  classes  known  as  relations. 
The  instances  of  a  relation  are  assertions  that  pairs  of 
objects  belong  to  the  relation.  The  four  programs  for  a 
relation  add  assertions,  remove  assertions,  test  that  a  pair  of 
objects  is  a  member  of  the  relation,  and  given  an  object  "x", 
fetch  all  objects  "y"  for  which  an  assertion  of  the  relation 
between  "x"  and  "y"  holds. 

In  addition  to  the  basic  mechanism  for  describing  their 
behaviour,  classes  are  provided  with  a  means  of  defining  the 
properties  which  instances  may  have.  For  example,  one  might 
define  the  class  "PERSON"  whose  instances  are  people,  and 
include  in  the  definition  a  description  of  the  property  "eye 
colour".  Instances  of  the  class  may  then  have  values  for  these 
properties;  thus  the  object  "John"  might  have  the  value  "blue" 
for  the  property  "eye  colour".  This  mechanism  is  similar  to 
the  binary  relations.  For  example,  an  alternative  to  defining 
"eye  colour"  as  a  property  in  "PERSON",  one  could  define  a 
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relation  "EYE  COLOUR"  whose  domain  is  "PERSON"  and  range  is 
"COLOUR".  The  former  mechanism  is  used  for  properties  which 
the  designer  of  the  knowledge  base  considers  to  be 
definitional:  properties  which  characterize  the  objects.  For 
example,  one  might  consider  a  person’s  social  insurance  number 
and  sex  as  definitional  properties.  Once  assigned,  the  values 
of  such  properties  may  not  be  changed. 

The  four  programs  associated  with  a  class  or  relation  are 
attached  as  property  values  of  that  class  or  relation.  The 
definitions  of  these  properties  are  provided  in  the  classes 
"CLASS"  and  "RELATION".  Thus  "CLASS"  contains  definitions  of 
the  properties  "to  add",  "to  remove",  "to  test",  and  "to  fetch" 
and  "RELATION"  provides  similar  definitions  for  relations. 
Classes  such  as  "CLASS"  and  "RELATION"  which  have  classes  as 
instances  are  known  as  metaclasses. 

The  definition  of  a  property  in  a  class  is  represented  by 
an  object  associated  with  the  class.  Such  an  object  is  called 
a  slot  and  is  said  to  exist  in  a  class.  Slots,  being  objects, 
will  themselves  have  property  values.  These  values  serve  to 
provide  the  constraints  on  the  property  values  of  instances  of 
the  class.  An  important  example  is  the  "type"  property  of  a 
slot.  A  property  value  of  an  instance  of  a  class  must  be  an 
instance  of  every  member  of  the  set  of  classes  which  is  the 
type  of  the  corresponding  slot.  If  the  type  of  the  slot  "eye 
colour"  in  the  above  example  were  "COLOUR",  only  colours  may  be 
the  corresponding  property  values,  and  for  "John"  to  have  "eye 
colour"  "blue"  it  is  required  that  "blue"  be  an  instance  of 
"COLOUR".  The  exact  mechanism  used  for  defining  the  properties 
of  slots  is  one  of  the  concerns  of  this  paper. 

In  continuing  the  example,  there  may  arise  a  need  to 
discuss  more  specialized  classes  of  colours.  For  example,  in 
discussing  eye  colours  one  might  wish  to  distinguish  a  class  of 
brown  eye  colours  such  as  brown  and  hazel  from  a  class  of  blue 
eye  colours.  One  would  then  use  the  classes  "BROWN  COLOURS" 
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and  "BLUE  COLOURS".  It  is  however  desirable  that  any  instance 
of  these  classes  remains  an  instance  of  the  class  "COLOUR". 
This  specialization  can  be  represented  through  the  PSN  supplied 
relation  IS-A.  If  IS-A  holds  between  "BROWN  COLOURS "  and 
"COLOUR",  "BROWN  COLOURS"  is  a  subclass  or  IS-A  child  of 
"COLOUR"  and  "COLOUR"  is  a  superclass  of  "EROWN  COLOURS".  Now, 
if  "brown"  is  an  instance  of  the  subclass,  it  is  automatically 
an  instance  of  the  superclass. 

It  is  the  responsibility  of  the  four  programs  associated 
with  the  classes  to  insure  that  IS-A  behaves  in  the  proper 
manner.  If  "B"  is  a  subclass  of  "A",  the  program  which  adds  an 
instance  to  "B"  must  also  make  the  object  an  instance  of  "A". 
In  other  words,  once  the  add  program  of  "B"  has  been  run  with 
an  object  "b"  as  a  parameter,  the  test  program  of  "A"  must 
recognize  this  object  as  an  instance  of  "A",  the  fetch  program 
should  fetch  it,  and  the  remove  program  should  remove  from  "A" 
(and  at  the  same  time  from  "B") .  The  representation  of 
programs  in  PSN  provides  a  relationship  between  programs  which 
constrains  the  assignment  of  programs  to  subclasses  of  a  class. 
When  this  relation  holds  between  the  programs  "p"  and  "g"  where 
"g"  is  the  add  program  for  "A",  "p"  will  be  a  valid  add  program 
for  "B". 


Another  aspect  of  IS-A  which  is  relevant  here  is  the 
inheritance  of  structure  (the  set  of  slots  in  a  class).  When 
one  defines  a  class  "BROWN  EYED  PERSON"  as  a  subclass  of 
"PERSON",  the  slot  "eye  colour"  is  automatically  contained  in 
the  new  class.  The  properties  of  the  slot  may  be  modified  in 
this  process  of  inheritance.  In  the  example,  one  would 
constrain  the  type  of  the  "eye  colour"  to  be  "EROWN  COLOUR"  so 
that  all  instances  of  the  new  class  may  have  only  eye  colours 
which  are  instances  of  "BROWN  COLOUR".  In  general,  when  a 
property  of  a  slot  is  modified  in  inheritance,  the  new  value 
must  be  an  IS-A  descendant  of  the  inherited  value  (as  "BROWN 
COLOUR"  is  a  subclass  of  "COLOUR") . 
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3.  Programs 

Each  PSN  program  consists  of  three  groups  of  statements: 
the  prerequisites ,  the  bod y,  and  the  returns  statement.  This 
division  of  programs  into  parts  is  intended  to  simplify  the 
writing  and  understanding  of  programs.  In  earlier  versions  of 
PSN,  a  fourth  group  of  statements  was  included  to  handle  cases 
where  failure  occurred  in  the  execution  of  the  body.  This  has 
been  replaced  by  a  more  general  exception  handling  mechanism 
based  on  that  of  TAXIS.  TAXIS  programs  too  include  a  fourth 
group  of  statements  called  results  or  post  conditions  which 
have  not  yet  been  incorporated  into  PSN. 

The  execution  of  a  program  begins  by  the  evaluation  of  the 
prerequisites.  Should  any  of  these  not  return  true  the 
exception  handling  mechanism  is  invoked.  This  involves  the 
creation  of  an  object  called  an  exception  which  describes  the 
circumstances  of  the  failure.  The  process  which  failed  is 
terminated.  The  calling  program  may  provide  a  procedure  to 
handle  this  exception.  The  value  returned  by  this  exception 
handler  is  used  in  place  of  the  value  which  the  failed  program 
might  have  returned.  Thus  a  program  for  division  might  have  as 
a  prerequisite  a  check  that  the  divisor  is  not  zero.  If  this 
prerequisite  fails,  the  calling  routine  could  replace  the 
division  by  a  program  which  simply  returns  an  arbitrary  value, 
for  example  zero. 

Once  the  prerequisites  have  succeeded,  the  statements  of 
the  body  are  executed.  These  statements  perform  the  major 
functions  of  the  program,  possibly  modifying  the  knowledge 
base.  Once  the  statements  of  the  body  have  all  been  executed, 
the  expression  in  the  final  group  is  executed  returning  the 
value  which  is  to  be  returned  by  the  program. 

The  statements  of  the  body  of  the  program  may  cause 
changes  in  the  contents  of  the  knowledge  base.  Such  changes 
fall  into  two  categories:  the  first  is  the  set  of  changes 
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caused  by  the  interpreter  as  it  executes  the  program;  the 
second  is  the  set  of  changes  a  statement  is  intended  to 
perform.  The  first  category  of  changes  is  generally  not 
permanent:  that  is,  when  the  execution  of  the  program  is 
complete,  the  state  of  the  knowledge  base  will  be  unchanged 
except  for  the  changes  in  the  second  category.  The  second 
category  of  changes  is  known  as  the  set  of  side  ef feet s  of  the 
program.  As  an  example,  one  side  effect  of  an  add  program  will 
generally  be  a  link  joining  an  object  to  a  class. 

Not  all  of  the  side  effects  of  a  statement  in  the  body 
remain  when  the  program  is  completed.  It  is  possible,  for 
example,  that  a  statement  near  the  beginning  of  execution  will 
assert  a  relation  between  two  objects  and  that  a  later 
statement  will  undo  this  assertion.  The  net  side  effects  of  a 
program  are  those  side  effects  which  remain  when  execution  is 
complete.  In  other  words,  the  set  of  net  side  effects  of  a 
program  is  the  set  cf  differences  between  the  knowledge  base 
before  execution  and  the  knowledge  base  after  execution.  A 
function  is  a  program  which  has  no  net  side  effects  under  any 
conditions  (for  any  set  of  parameters  in  any  state  of  the 
knowledge  base) .  Functions  are  the  only  programs  which  may  be 
invoked  when  the  returns  statement  of  a  program  is  being 
executed.  The  prerequisites  must  also  invoke  only  functions. 
Thus  the  side  effects  of  any  program  must  be  performed  by  the 
statements  of  the  body. 

The  side  effects  of  a  program  are  further  constrained  by 
the  fact  that  all  of  the  statements  in  any  group,  that  is 
prerequisites  or  body,  are  to  be  executed  simultaneously.  Thus 
if  more  than  one  prerequisite  fails,  a  number  of  exceptions 
will  be  raised.  In  the  case  of  the  body,  this  implies  that  the 
side  effects  of  one  statement  may  not  depend  on  those  of 
another.  For  example,  one  may  not  include  two  statements  where 
the  first  creates  an  object  and  the  second  asserts  that  this 
object  participates  in  some  relation  because  one  cannot 
guarantee  that  the  new  object  exists  when  the  assertion  is 
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attempted.  This  restriction  will  become  significant  when  the 
specialization  of  programs  is  considered. 

4.  Programs  as  Classes 

When  representing  programs  in  PSN  one  would  like  to  use 
the  tools  for  organizing  knowledge  already  existing  in  the 
formalism.  Thus  the  relation  representing  specialization  of 
programs  becomes  IS-A  and  classes  represent  programs.  Py 
associating  the  statements  of  a  program  with  the  slots  of  a 
class,  the  existing  inheritance  mechanisms  provide  restrictions 
on  the  specialized  programs.  Also,  using  classes  as  programs 
allows  the  use  of  instances  of  these  classes  to  represent 
activations  of  a  the  programs.  Such  instances  of  programs  are 
known  as  processes. 

Consider  as  an  example  a  program  which  will  compute  the 
reciprocal  of  its  argument.  It  will  have  a  parameter,  say  "x", 
which  is  a  number,  a  prerequisite  which  checks  that  "xM  is  not 
zero,  and  a  returns  statement  which  divides  one  by  "x".  This 
program  can  be  represented  in  PSN  as  follows  {the  details  will 

y 

be  explained  as  the  text  develops  the  representation) : 

(invert  INSTANCE-OF  PROGRAM 
STRUCTURE 

(x  INSTANCE-OF  parameters 

PROPERTY- VALUES  type  NUMBER) 

(not-egua 1-zero 

INSTANCE-OF  prerequisites 
PROPERTY- VALUES 

eval 

(# 1-not-equal 

INSTANCE^CF  PROGRAM  FORM 
IS-A  not -equal 
STRUCTUP E 

(left 

INSTANCE-OF  ac tion_par ame ters 
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PROPERTY-VALUES  eval  x) 
(right 

INSTANCE-OF  quote_parameters 
PROPERTY- VALUES  quote  0)  ) 
exception  [new  ZERO-DIVIDE  ]) 
(divide-arg  I NSTA NCE-OF  returns 
PR  0 P ER TY-VALUES 

eval 

( # 1 -divide 

INSTANCE-OF  FORM  PROGRAM 

IS-A  divide 

STRUCTURE 

(lef t-d 

INSTANCE-OF  q uote_ para  mete rs 
PROPERTY- VALUES  quote  1) 
(right-d 

INSTANCE-OF  ev al_param eter 
PROPERTY-VALUES  eval  x) ) ) ) . 


The  notation  used  to  illustrate  the  program  represents  an 
object,  by  a  list  enclosed  in  parentheses  or  by  an  exte rnal  name 
which  acts  as  a  reference  to  the  object.  In  the  list 
representation  of  an  object,  the  first  string  is  the  external 
name  which  will  be  used  to  refer  to  that  object.  The  remainder 
of  the  list  consists  of  keywords  followed  by  references  to 
objects.  The  INSTANCE-OF  keyword  is  followed  by  a  list  of  the 
classes  of  which  the  object  is  an  instance;  for  example, 
’'invert"  is  an  instance  of  the  metaclass  "PROGRAM".  The  IS-A 
keyword  is  followed  by  the  classes  of  which  a  class  is  a 
subclass;  in  the  example,  "# 1-not-eq ual"  is  a  subclass  of 
"not-equal".  The  STRUCTURE  keyword  is  followed  by  a  list  of 
objects  contained  in  the  structure  of  a  class.  The  structure 
of  "invert"  contains  the  slots  "x",  "not-equal-zero" ,  and 
"divide-ar gs".  Finally,  the  keyword  PROPERTY-VALU ES  precedes  a 
list  of  pairs  of  objects  of  which  the  first  object  is  a  slot 
and  the  second  the  corresponding  property  value.  In  the 
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example  the  object  "di vide-args"  has  as  its  "eval"  property 
value  the  object  " #1 -divide". 

The  illustrations  of  objects  will  in  general  include  only 
relevant  and  non-redundant  detail.  For  example  "PROGRAM"  is  a 
subclass  of  "CLASS",  therefore  "invert"  is  an  instance  of 
"CLASS",  but  only  "PROGRAM"  is  mentioned  in  the  INSTANCE-OF 
list.  In  the  case  of  structure,  inherited  objects  are  shown 
only  if  their  property  values  differ  from  those  they  have  in  an 
I S- A  parent. 

The  nature  of  a  PSN  program  is  determined  by  its  slots  and 
their  properties.  One  role  that  any  slot  in  a  program  plays  is 
that  of  a  location  for  storing  a  value.  The  value  stored  for  a 
given  slot  in  a  given  activation  is  the  property  value  bound  to 
the  process  representing  the  activation.  In  the  language  of 
PSN,  the  slot  plays  the  role  of  a  variable,  although  it  is  not 
truly  variable  in  that  a  property  value  of  an  object,  once 
bound,  may  never  be  changed.  This  may  at  first  appear  to  be  a 
severe  restriction  for  programs  requiring  iteration.  It  is, 
however,  possible  to  implement  iterative  control  structures 
using  recursion.  Such  an  implementation  of  a  FOR  loop  is 
illustrated  in  J Kramer  1980]. 

The  parameter  "x"  of  the  program  "invert"  illustrates  the 
use  of  a  PSN  variable.  The  object  "#1-divide"  is  an  expression 
in  the  program;  the  use  of  "x"  as  the  "eval"  property  value  of 
the  slot  "right-d"  indicates  that  the  value  of  the  property  "x" 
will  be  used  in  the  division.  The  variable  binding  mechanism 
which  results  is  static:  the  use  of  "x"  in  the  expression 
"#  1-divide"  will  always  mean  "x"  in  the  program  "invert". 

Such  a  reference  to  a  variable  in  an  expression  of  a 
program  may  be  to  any  slot  in  any  program  in  the  knowledge 
base.  The  interpreter  will  have  to  decide  from  which  instance 
of  the  program  containing  the  slot  the  binding  should  be  taken. 
This  situation  is  similar  to  that  occurring  in  recursion  in 
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other  programming  languages.  The  use  of  a  variable  "X"  in  a 
recursive  ALGOL  program  refers  to  the  value  stored  in  the  most 
recent  activation  of  the  procedure.  The  PSN  mechanism  provides 
the  same  effect. 

What  is  required  is  a  mechanism  for  maintaining  a  record 
of  the  order  of  activation  of  programs.  This  is  done  through 
assertions  of  the  relation  "dynamic"  between  processes.  For 
example,  the  execution  of  "invert"  will  be  represented  by  a 
process,  say  "invertl".  At  some  point  in  the  execution,  the 
program  "divide"  will  be  invoked.  An  instance  of  "divide",  say 
"dividel"  will  be  created  and  linked  to  "invertl"  with  an 
assertion  of  "dynamic".  Now,  when  a  slot  is  referenced  as  a 
variable  the  interpreter  searches  the  chain  of  "dynamic"  links 
for  the  first  process  that  is  an  instance  of  a  program 
containing  that  slot.  Thus,  when  the  reference  to  "x"  occurs 
in  "dividel",  the  interpreter  will  search  along  the  "dynamic" 
assertions  starting  at  "dividel".  Since  "invertl"  is  an 
instance  of  "invert"  which  is  the  class  containing  "x",  the 
value  of  the  variable  is  associated  with  "invertl". 

The  second  role  played  by  slots  in  a  program  is  that  of 
statements  of  the  program.  A  statement  consists  of  a  slot  and 
an  associated  form,  a  PSN  object  which  represents  an 
expression.  Examples  of  forms  in  "invert"  are  " #1-not-egual " 
and  "#1-divide".  When  the  statement  is  executed,  the  value 
resulting  from  the  execution  of  the  form  becomes  the  value  of 
the  slot  in  its  role  as  a  variable.  For  example,  if  the 
process  "invertl"  had  value  "5"  for  the  property  "x",  it  would 
receive  value  "true"  for  the  property  "not-egua 1-ze ro"  after 
the  execution  of  the  form  " # 1-not-egual"  (five  does  not  egual 
zero)  . 


The  expressions  associated  with  the  slots  in  programs  are 
objects  which  provide  a  value,  either  as  calls  to  other 
programs  as  in  the  slot  "not-egual-zero" ,  or  as  references  to 
the  values  of  other  slots  as  in  the  slot  "left"  of 
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"#  1-not-equal" .  When  used  as  a  call  to  another  program,  the 
form  provides  a  mapping  between  the  parameters  of  the  program 
to  be  called  and  variables  in  the  scope  of  the  calling  programs 
lor  expressions  in  such  variables).  In  programming  languages 
this  binding  is  usually  represented  positionally.  For  example, 
in  ALGOL  a  procedure  of  two  arguments  called  "F00"  is  called  by 
the  form  "FOO[X,Y)n  where  "X"  and  "Y"  are  variables  known  in 
the  calling  program.  The  values  are  bound  to  the  parameters 
appearing  in  the  same  position  in  the  definition  of  "F00". 
PSN,  however,  performs  this  binding  by  including  explicit  links 
from  the  parameters  of  a  copy  of  the  program  to  variables  or 
other  forms.  This  copy  of  the  program  is  an  instance  of  the 
class  " FORM "  and  at  the  same  time  an  IS-A  child  of  the  program. 
It  therefore  inherits  the  structure  of  the  program,  and  in 
particular  the  parameters  slots  of  the  program.  The  bindings 
of  the  parameters  are  represented  by  "eval"  property  values  of 
these  slots. 

Often  in  a  form  one  will  wish  to  use  a  constant  instead  of 
another  expression.  In  such  cases,  the  value  provided  for  a 
parameters  slot  is  taken,  not  from  an  "eval"  property  value, 
but  from  a  "quote”  property  value.  Thus  there  are  two  ways  of 
binding  the  parameters  of  a  program  to  produce  a  form.  A  PSN 
form  is  either  a  slot  or  a  subclass  of  a  program  whose 
parameters  are  bound  by  either  an  "eval"  property  to  another 
form  or  by  a  "guote"  property  to  any  object.  In  the  example, 
the  "quote"  property  is  used  in  the  form  " # 1-not-e gual "  to  bind 
the  parameter  "right"  to  the  value  "0". 

5.  Metastructure 


When  the  various  constructs  in  a  program  are  represented 
by  slots  there  must  be  a  mechanism  for  distinguishing  the 
functions  of  these  objects.  The  interpreter  must  be  able  to 
decide  whether  a  given  slot  is,  say,  a  prerequisite  or  a 
parameter.  Also,  it  will  be  necessary  to  fetch  all  the 
prerequisites  or  all  the  slots  of  the  body.  In  addition. 
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mechanism  is  reguired  for  associating  expressions  with  slots. 
The  metastructure  concept  is  introduced  to  enable  these 
operations . 

The  objects  in  the  structure  of  a  class  are  categorised 
because  they  must  be  instances  of  classes.  These  classes  are 
contained  in  the  structures  of  metaclasses.  If  "A"  is  a  class 
and  B  is  the  set  of  metaclasses  of  which  it  is  an  instance, 
then  each  object  in  the  structure  of  "A!1  must  be  an  instance  of 
some  object  in  the  structure  of  some  member  of  B.  The 
metaclasses  therefore  organize  the  structure  of  the  class.  For 
example,  the  metaclass  "PROGRAM"  contains  the  objects 
" prereguisites" ,  "body",  and  "returns",  therefore  the  slots  of 
a  program  may  be  distinguished  by  the  classes  of  which  they  are 
instances.  In  the  program  "invert"  of  the  previous  section  the 
slot  "not- egual-zero"  is  an  instance  of  "prereguisites"  and  the 
slot  "divide-arg"  is  ar  instance  of  "returns".  Objects  in  a 
metaclass  whose  instances  are  slots  are  known  as  meta slots  and 
the  subset  of  the  structure  containing  metaslots  is  called  the 
metastructure  of  the  class. 

Since  they  have  instances,  metaslots  must  be  classes.  As 
classes,  they  may  define  the  properties  of  their  instances. 
The  prime  example  of  a  metaslot  in  this  role  is  the  class 
"slot"  which  has  all  slots  as  instances.  This  class  is  a  part 
of  the  metastructure  of  the  metaclass  "CLASS"  thereby  allowing 
any  class  to  contain  slots.  The  structure  of  "slot"  consists 
of  definitions  for  the  type,  default,  and  restriction 
properties  of  slots.  It  is  interesting  to  note  that  the 
structure  of  "slot"  is  made  of  instances  of  itself.  This  works 
because  it  is  an  instance  of  "CLASS"  as  well  as  being  a  member 
of  the  structure  of  "CLASS". 

The  class  "slot"  is  important  in  PSN  because  only 
instances  of  this  object  define  properties  of  instances  of 
classes.  Thus  any  metaslct  must  be  a  subclass  of  "slot".  One 
reason  for  specializing  "slot"  is  to  provide  more  properties  to 
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a  class  of  slots.  For  example,  the  metaclass  "PROGRAM" 
contains  a  metaslot  called  "ac tion_slct "  which  defines  a  new 
property  called  "eval".  The  value  of  the  "eval"  property  of  a 
slot  is  the  associated  expression  necessary  in  the  definition 
of  programs.  Since  ,,action_slotu  is  a  subclass  of  slot,  any 
instance  of  the  metaslot  will  have  all  of  the  properties  of 
regular  slots. 

In  inheritance,  all  elements  of  a  structure  are  treated 
uniformly.  Slots  and  metaslots  are  inherited  in  the  same  way. 
If  "E"  is  a  subclass  of  "A"  and  C  is  the  set  of  classes  of 
which  "B"  is  an  instance,  "B"  will  inherit  all  objects  in  the 
structure  of  "A"  which  are  instances  of  some  object  in  the 
structure  of  some  member  of  C.  When  objects  in  a  structure  are 
inherited,  property  values  may  be  modified  subject  to  the  rule 
that  the  new  values  must  be  IS-A  descendants  of  the  old. 
(Where  the  values  are  not  classes  they  must  remain  unchanged.) 

A  new  aspect  of  inheritance  is  that  the  inherited  object 
may  be  made  an  instance  of  more  classes  so  long  as  it  remains 
an  instance  of  each  class  of  which  it  was  an  instance  in  the 
IS-A  parent.  For  example,  the  parameters  of  certain  subclasses 
of  programs  may  be  of  one  of  two  types  represented  by  the 
subclasses  "action_pa rame ters"  and  "guote_parameter s"  of  the 
metaslot  "parameters".  When  a  program  is  specialized, 
parameters  slots  which  are  simply  "parameters"  in  the  IS-A 
parent  may  become  instances  of  one  or  the  other  subclasses  of 
"parameters".  This  is  illustrated  by  the  slot  "left"  of  the 
form  ”# 1-not-egual"  as  shown  in  the  example  of  section  four. 
In  the  program  "not-egual"  from  which  it  is  inherited,  the  slot 
would  be  an  instance  of  the  metaslot  "parameters".  In  the  form 
" # 1-not-egual"  it  is  an  instance  of  "action_para meters" .  The 
specialized  slot  will  however  also  remain  an  instance  of 
"parameters"  and  thus  satisfy  the  rules  of  inheritance. 

The  class  "slot"  in  particular,  and  metaslots  in  general, 
must  be  instances  of  objects  in  the  structures  of  higher  levels 
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of  classes.  The  class  "H ET ACLAS5 "  containing  the  metaclass 
"metaslot"  is  introduced  for  this  purpose.  "METACLASS"  is  an 
instance  of  itself,  as  is  "metaslo t" .  In  this  way  one  avoids 
the  introduction  of  an  endless  chain  of  classes  each  providing 
the  means  for  the  definition  of  structure  in  its  instances. 

"in  eta  slot”  is  an  instance  of  an  element  of  the  structure - 

"metaslot"  -  of  a  class  -  "METACLASS"  -  of  which  its 

containing  class  is  an  instance.  "METACLASS"  is  the  class  of 
all  metaclasses  and  "metaslot"  the  class  of  all  metaslots. 
However,  an  instance  of  "METACLASS"  is  a  true  metaclass  only  if 
it  is  a  subclass  of  "CLASS",  and  similarily,  an  instance  of 
"metaslot"  must  be  a  subclass  of  "metaslot"  to  be  a  true 
me  taslot. 

In  many  cases  it  will  be  desirable  to  limit  the  number  of 
instances  of  a  given  metaslot  in  a  class  by  specifying  upper 
and  lower  bounds  on  this  number.  For  example,  programs  may 
have  only  one  slot  whose  associated  expression  which  computes 
the  value  to  be  returned.  2SN  introduces  the  slot  called 
"interval"  to  the  class  "metaslot".  ("metaslot"  may  have  slots 
because  it  is  itself  a  class  and  metaclass.)  The  interval  of  a 
metaslot  is  an  ordered  pair  of  numbers  which  specify  the 
minimum  and  maximum  number  of  that  kind  of  slot  which  may 
appear  in  a  class.  This  pair  is  used  by  the  add  program  of 
"CLASS"  as  the  last  operation:  for  each  metaslot  in  each  parent 
class  it  will  fetch  the  instances  of  the  metaslot  in  the  newly 
created  object  and  check  that  the  number  of  such  instances 
falls  in  the  interval  of  the  metaslot.  The  raetaslot  "slot"  has 
an  interval  [0,*)  where  the  *  represents  infinity  meaning  that 
any  class  may  have  any  number  of  slots. 

One  can  now  discuss  how  the  various  aspects  of  programs 
can  be  represented  as  slots.  All  programs  will  be  instances  of 
the  metaclass  "PEOGEAM"  which  has  a  metastructure  describing 
the  various  parts.  Hence  there  are  metaslots  called 
"parameters",  "prerequisites",  "body",  and  "returns".  Any 
slots  which  are  not  instances  of  these  metaslots  may  be  used  as 
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local  variables.  The  metaslots  now  provide  the  mechanism  for 
distinguishing  the  purpose  of  the  slots  of  a  program.  For 
example,  if  the  interpreter  needs  the  prereguisit es  of  a 
program  it  can  search  the  set  of  slots  making  a  list  of  all 
those  which  are  instances  of  the  metaslot  "prereguisit es" . 

An  earlier  example  showed  the  definition  of  the  property 
"eval"  which  is  used  for  associating  expressions  with  slots. 
This  definition  is  contained  in  the  metaslot  "act ion_slot "  in 
the  metaclass  "PROGRAM".  The  various  categories  of  executable 
slots  acguire  this  property  because  the  metaslots  "body", 
"prerequisites",  and  "returns"  are  subclasses  of  " action_slot" , 
inheriting  its  structure.  Two  other  special  properties  are 
defined  for  executable  slots  in  the  same  way.  These  are  the 
"exception"  property  which  is  an  expression  which  may  be 
evaluated  to  create  an  exception  should  evaluation  of  the  slot 
fail,  and  an  "exception_action"  property  which  specifies 
exception  handlers  to  be  used  should  an  exception  be  created. 

In  general  a  program  may  have  an  arbitrary  number  of 
statements  in  each  class.  Hence  the  intervals  for  the 
parameters,  prerequisites,  and  body  are  [0,*).  However,  the 
"returns"  slot  must  be  unigue,  so  the  interval  for  "returns"  is 
[1,1]  so  that  a  value  to  be  returned  is  always  computed. 

6 •  Specialization 

A  primary  reason  for  representing  programs  as  classes  is 
the  consequent  ability  to  specialize  programs  through  the  use 
of  I S—  A .  This  allows  uniform  treatment  of  the  inheritance  of 
property  values  between  IS-A  related  classes.  In  general,  the 
property  values  of  a  subclass  should  be  IS-A  descendants  of  the 
corresponding  property  values  of  the  superclass.  Since 
programs  are  property  values  of  classes,  the  use  of  IS-A  is 
clearly  indicated. 

The  structural  constraints  imposed  by  IS-A  on  related 
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programs  are  however  not  sufficient  to  insure  that  the  four 
programs  of  a  subclass  act  correctly  with  respect  to  IS-A.  It 
is  necessary  to  consider  programs  in  terms  of  their  side 
effects  and  the  values  returned. 

A  first  consideration  is  the  add  program  of  a  class.  An 
object  is  made  an  instance  of  a  class  through  the  side  effects 
of  the  add  program  of  the  class.  If  a  subclass  of  this  class 
has  an  add  program  whose  net  side  effects  include  those  of  the 
original  add  program,  any  object  of  the  subclass  must  surely  be 
an  instance  of  the  superclass.  Thus  one  constraint  on  the 
specialization  of  programs  is  that  the  net  side  effects  of  the 
specialization  include  the  net  side  effects  of  the  original. 

The  structural  constraint  of  IS-A  inheritance  combined 
with  the  simultaneous  execution  of  body  slots  goes  a  long  way 
towards  this  goal.  Any  new  slot  added  in  inheritance  may  not 
undo  the  side  effects  of  an  inherited  slot  because  one  cannot 
be  sure  that  the  new  action  will  be  performed  after  the 
inherited  action  in  any  execution  of  the  program.  One  cannot 
remove  an  object  from  a  class  before  it  has  been  made  an 
instance  of  the  class. 

The  net  side  effects  of  an  inherited  program  can,  however, 
exclude  some  of  those  inherited  because  there  exists  in  PSN  a 
way  of  causing  forms  to  be  executed  sequentially.  This  is  done 
through  the  use  of  the  program  "BEGIN".  This  program  takes  two 
arguments  called  "argl"  and  "arg2"  of  types  "OBJECT"  (that  is 
any  object)  and  "FCBM "  respectively.  Evaluation  is  simple:  if 
the  second  parameter  has  as  value  the  object  "NULL_FOFM",  the 
program  returns  the  value  of  the  first  parameter,  otherwise  it 
applies  the  interpreter  to  the  value  of  "arg2".  The  value 
returned  in  the  latter  case  is  the  result  of  the  evaluation  of 
the  form.  If  a  chain  of  forms  calling  " EEGIN"  is  formed  with 
the  first  parameter  of  each  form  having  as  an  "eval"  property  a 
form  and  the  second  parameter  having  as  a  "quote"  property 
value  the  next  subclass  of  "BEGIN",  one  has  a  chain  of  forms 
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which  will  be  executed  seg uentially .  The  object 
(begin-cha  in 

INSTANCE-OF  FORM  PROGRAM 

IS- A  BEGIN 

STRUCTURE 

(argl 

INSTANCE-OF  ac tion_parame ter s 
PROPER TY^V A LUES  eval  FI) 

(arg2 

INSTANCE-OF  guote_ parameters 
PROPERTY-VALUES 

quote 

(begin-chain2 

INSTANCE-OF  FORM  PROGRAM 

IS— A  BEGIN 

STRUCTURE 

(argl 

INSTANCE-OF  ac tion_par ameters 
PROPERTY-VALUES  eval  F2) 

(arg2 

INSTANCE-OF  guote_paramete rs 
PROPERTY-VALUES  quote  NULL_FOR M) ) ) ) 

for  example,  is  a  form  which  calls  "BEGIN"  in  which  the  form 
"FI"  will  always  be  executed  before  the  form  "F2".  This 
results  because  the  execution  sequence  begins  by  the  creation 
of  an  instance  of  "begin- chain"  for  which  parameter  values  are 
supplied  by  evaluating  the  value  of  "argl"  thus  evaluating 
"FI",  and  taking  the  value  of  "arg2"  as  is-  "F2"  is  evaluated 
only  when  the  interpreter  is  applied  to  "begin-cha in2"  after  it 
is  discovered  that  the  value  of  "arg2"  is  not  "NULL_FORM". 

When  inheriting  such  "BEGIN"  structures,  one  may  have  a 
problem  with  side  effects.  Any  form  may  be  a  subclass  of 
"NULL_FORM"  (because  it  has  no  structure).  Thus  one  can  modify 
an  inherited  "BEGIN"  chain  by  adding  more  calls  to  "BEGIN"  at 
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the  end  because  any  form  {eg.  a  call  to  "BEGIN" )  can  be  a 
subclass  of  "NULL_FORM".  Thus  the  structural  IS-A  constraints 
will  be  satisfied.  However  these  additional  forms  will  always 
be  executed  after  the  inherited  forms  in  the  same  "EEGIN"  chain 
and  therefore  may  undo  the  side  effects  intended  by  the 
inherited  forms.  For  example,  a  valid  IS-A  descendant  of 
"begin-chain"  is  represented  by 

(subclass-of-be gin- chain 
INSTANCE-OF  FORM  PROGRAM 
IS- A  begin-chain 
STRUCTURE 

(arg2 

INSTANCE-OF  quote_ parameters 
PROPERTY- VALUES 

quote 

(subcla ss-o f- be gin-chain 2 
INSTANCE-OF  FORM  PROGRAM 
IS-A  begin-chain2 
STRUCTURE 

(arg2 

INST ANCE-OF  guote_parameters 
PROPERTY-VALUES 

quote  F3)  . 

The  IS-A  constraints  are  satisfied  in 

"subclass-of-begin-chain2"  because  the  only  change  is  a 
modification  to  a  property  value  of  "arg2"  in  which  the  new 
value,  "F 3" ,  is  an  IS-A  descendant  of  the  old  value.  The  new 
form  "F3"  will  always  be  executed  after  "FI"  and  "F2"  and 
therefore  may  with  certainty  undo  some  side  effects  performed 
by  the  original  forms. 

The  PSN  solution  to  this  problem  is  to  provide  an 
additional  constraint  on  the  use  of  IS-A  for  specializing 
programs.  IS-A  may  hold  between  two  programs  only  if  in  any 
possible  knowledge  base  the  set  of  net  side  effects  produced  by 
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the  specialization  must  contain  the  set  of  net  side  effects 
which  would  be  produced  by  the  IS-A  parent  if  run  with  the  same 
parameters . 

A  final  constraint  on  the  use  of  IS-A  for  programs  results 
from  consideration  of  the  values  returned  by  the  programs.  In 
particular,  the  results  of  test  programs  are  interesting.  If 
class  "B"  is  a  specialization  of  class  "A",  and  "Pb"  and  "Pa" 
are  the  respective  test  programs,  one  finds  that  if  "Pb" 
returns  true,  "Pa”  must  return  true  because  an  instance  of  "  B" 
is  always  an  instance  of  "A".  However,  "Pa"  may  return  true 
for  an  instance  of  "A"  which  is  not  an  instance  of  "B".  The 
relation  between  the  values  returned  is  logical  implication: 
the  value  returned  by  "Pb"  implies  the  value  returned  by  "Fa". 
Now  nothing  in  the  structure  of  programs  obviously  relates  the 
values  returned.  Therefore,  a  program  "P2"  may  only  be  a 
specialization  of  "PI"  if,  when  returning  Eoolean  values  under 
identical  conditions,  the  result  of  "P2"  implies  that  of  "PI" 
and  when  not  returning  Boolean  values,  the  results  of  the  two 
programs  under  identical  conditions  are  identical. 

The  two  extra  conditions  on  programs  cannot  be  tested  in  a 
knowledge  base  system.  However,  if  an  effort  is  made  to 
minimize  the  changes  to  a  "returns"  slot  and  to  avoid  adding 
statements  causing  side  effects  to  "BEGIN"  chains,  it  should  be 
possible  to  write  programs  for  which  IS-A  may  properly  be 
asserted . 

7.  Conclusion 


The  representation  of  programs  as  objects  in  the  PSN 
formalism  has  several  useful  conseguences.  Most  important  is 
the  interaction  with  the  IS-A  hierarchy.  Programs  themselves 
participate  in  a  strictly  controlled  IS-A  relationship  which 
constrains  the  programs  which  play  the  various  roles  in  the 
definition  of  a  class  in  a  way  that  insures  that  classes 
related  by  IS-A  behave  in  the  appropriate  manner.  In  addition. 
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the  inheritance 

resulting  from  IS-A 

and 

the  separ 

programs 

into 

separately  inheritable  statements  p 

powerful 

and 

flexible  programming 

tool . 

In  spe 

pr ogra  ms 

one 

may  add  and  modify 

parts 

of  a  pr 

automatically  inherit  the  unchanged  parts. 


The  representation  of  programs  as  objects  wi 
formalism  allows  the  manipulation  of  programs 
programs.  One  can  therefore  write  programs  which  c 
modify  programs,  and,  as  in  LISP,  one  can  write  an  in 
for  the  formalism  as  such  a  program.  The 
representation  of  program  activations  provides 
flexibility.  Programs  may  themselves  alter  the  flow  o 
to  produce  back  tracking  and  concurrent  processe 
manipulation  of  the  assertions  of  the  relation  "dynami 


A  final  result  is  the  introduction  of  metas 
Metastructure  provides  a  means  of  organizing  and  con 
the  slots  in  the  structures  of  classes.  This  h 
immediate  use  in  organizing  the  slots  of  a  program  t 
the  different  functional  divisions.  It  is  anticipa 
metastructure  may  find  uses  in  other  representation  fo 
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Abstr  act 


Contexts  play  an  important  part  in  PSN  (the  Procedural  Semantic 
Network  formalism).  This  paper  discusses  some  of  the  problems 
that  have  been  encountered  with  contexts  in  PSN  and  gives  an 
informal  presentation  of  the  current  definition  of  contexts  in 
PSN.  Particular  attention  is  paid  in  this  presentation  to  the 
notion  of  inheritance  along  the  context  hierarchy  and  its 
implications. 


1.  Introduction 

PSN  (the  Procedural  Semantic  Network  formalism)  is  a 
formalism  for  the  representation  of  knowledge.  The  basis  of  PSN 
(as  described  in  [Levesgue  1977  ]  and  [Levesque  and  Mylopoulos 
19*79])  is  the  notion  of  a  class  with  four  attached  procedures. 
These  procedures  are  responsible  for  adding  instances  to, 
deleting  instances  from,  recognizing  instances  of,  and 
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enumerating  the  instances  of  a  class. 

PSN  also  contains  several  traditional  semai  tic  network 
concepts  in  addition  to  this  procedural  basis.  These  concepts 
serve  in  part  to  impose  order  on  the  heterarchical  nature  of  the 
procedures.  In  fact,  throughout  the  remainder  of  this  paper  the 
procedural  base  of  PSN  may  be  largely  ignored  since  the  paper 
talks  about  these  organizational  principles,  in  particular 
contexts. 

The  main  organizational  semantic  network  principles  in  PSN 
include  the  INSTANCE-OF  relationship,  the  IS-A  relationship,  and 
properties  of  objects  {also  known  as  the  PAET-OF  relationship) . 
The  INSTANCE-OF  relationship  relates  an  object  to  the  classes  it 
is  an  instance  of.  The  IS-A  relationship  relates  a  sub-class  to 
a  super-class  and  thus  is  concerned  with  the  specialization  and 
generalization  of  concepts.  Properties  may  be  associated  with 
any  class  and  define  the  kinds  of  information  that  can  be 

incorporated  into  the  instances  of  the  class  and  thus  are 
concerned  with  the  aggregation  of  information.  All  of  these 
organizational  principles  are  well  described  in  the  papers 
mentioned  above  although  an  extension  to  properties  has  been 
added  to  PSN  and  is  discussed  in  [Kramer  1980  ]. 

One  non-standard  aspect  of  PSN  is  that  everything  in  PSN  is 

an  object  and  a  member  of  a  class.  This  means  that  classes 

themselves  are  members  of  other  classes,  notably  the  meta-class 
"CLASS" ,  and  thus  may  have  properties  as  defined  bv  "CLASS"  {such 
as  cardinality) .  So  in  PSN  a  typical  object  such  as  "John"  is  an 
instance  of  a  class,  namely  "PEFSON",  which  is  in  turn  an 

instance  of  "CLASS".  "CLASS"  itself  must  be  an  instance  of  a 
class  but  with  a  little  inspection  it  should  be  clear  that 
"CLASS"  itself  is  the  appropriate  class  thus  eliminating  the  need 
for  ever  more  higher  meta-classes. 
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2.  Contexts 

There  is  a  fourth  organizational  principle  in  PSN  which  has 
been  less  investigated  and  much  less  understood  than  the  above 
two.  This  principle  is  the  ability  to  group  objects  into 
contexts,  much  like  the  contexts  of  CONNIVER  [Sussman  and 
McDermott  1972]  or  the  partitions  of  Hendrix’s  partitioned  nets 
[Hendrix  1975,  1979],  Recently  a  formal  investigation  of  the 

properties  of  contexts  in  PSN  has  turned  up  some  surprising 
aspects  of  contexts  as  they  had  been  developed  as  well  as 
clarifying  many  points  concerning  contexts  and  their  interaction 
with  the  other  organizational  principles  of  PSN.  This  resulted 
in  a  formal  definition  of  contexts  [  Schneider  1979  ].  This  paper 
presents  contexts  in  PSN  in  a  much  less  formal  manner  than 
[Schneider  1979]  and  concentrates  on  inheritance  between 
conte  xts. 

Contexts  in  PSN  are  most  often  used  to  represent  alternate 
views  of  the  knowledge  base.  For  example,  one  context  could  be 
used  to  represent  the  real  world.  This  context,  perhaps  called 
"reality",  would  have  all  the  knowledge  pertaining  to  the  real 
world.  Another  context  could  then  be  used  to  represent  the  well 
known  alternate  world  where  fairies  exist.  This  context,  perhaps 
called  "fairy  world",  would  have  the  same  information  as 
"reality"  in  most  areas  but  would  not  correspond  to  "reality"  in 
other  areas  and  would  have  some  additional  information  in  yet 
ethers. 


3.  Contexts  and  Views 

when  contexts  are  considered  it  no  longer  suffices  to  think 
of  objects  in  isolation.  Instead,  it  is  necessary  to  look  at  an 
object  as  seen  in  a  context,  such  as  "John"  in  "reality"  or 
"FAIRY"  in  "fairy  world".  It  is  also  possible  to  consider  an 
object  in  two  or  more  different  contexts  such  as  "John"  in 
"reality"  versus  "John"  in  "fairy  world".  In  these  different 
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views  "John”  may  have  different  properties  but  the  views  are 
still  views  of  the  same  object. 

So  far  this  is  fairly  straightforward.  However,  in  PS  N 
contexts  are  objects  [because  everything  in  PSN  is  an  object) . 
Eut  objects  and  thus  also  contexts  cannot  be  considered  as 

objects  in  isolation  but  only  as  objects  as  seen  in  a  context. 
For  example,  "fairy  world"  as  seen  in  "fairy  world"  is  different 
from  "fairy  world"  as  seen  in  "reality".  This  interaction 
requires  a  change  in  the  definition  of  contexts. 

The  redefinition  of  contexts  in  PSN  proceeds  as  follows: 
First  a  view  in  PSN  is  defined  to  be  an  object  as  seen  in  a 
context.  Then  a  context  is  defined  to  be  a  special  type  of  view 
in  which  the  view  is  an  instance  of  the  object  "CONTEXT".  A 
little  inspection  of  this  definition  shows  that  there  is  no  way 
of  creating  any  non-infinite  views  [or  contexts)  since  any  view 
must  contain  another  view.  This  is  corrected  by  creating  a 

single  base  context,  the  universal  context.  The  universal 

context  is  thus  the  only  view  [and  context)  not  consisting  of  an 
object  as  seen  in  a  context  and  must  form  part  of  every  view  (and 
context)  in  PSN. 

This  makes  it  possible  to  create  contexts  and  views  of 

varying  complexity.  For  example,  the  object  "John"  as  seen  in 
the  universal  context  is  a  perfectly  ordinary  view,  essentially 
corresponding  to  "John"  in  PSN  without  contexts.  The  context 
"reality"  in  the  universal  context  is  an  ordinary  context  and 
"Eill"  as  seen  in  this  context  is  a  view  corresponding  to  a  view 
in  other  approaches  to  contexts.  This  situation  (plus  others 
mentioned  below)  is  illustrated  in  Figure  1.* 

♦In  each  figure  the  largest  box  represents  the  universal  context 
and  the  names  each  represent  a  view  with  those  names  that  are 
attached  to  boxes  representing  contexts.  The  containment 

relationship  in  the  figure  represents  the  'as  seen  in' 
relationship  between  objects  and  contexts  in  PSN.  Also 
unlabelled  single  arrows  represent  the  instance  relationship. 
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Tn  PSN  an  object  may  be  part  of  several  views  (as  is  "John" 
in  Figure  1)  and  if  an  object  forms  a  view  in  a  context  then  that 
object  can  be  referenced  in  the  context.  Each  view  of  an  object 
may  have  different  values  for  its  properties,  may  be  an  instance 
cf  different  classes,  and  thus  also  may  have  different 
properties.  The  views  of  "John"  in  "reality"  in  the  universal 
context  and  in  "fairy  world"  in  the  universal  context  in  Figure  1 
illustrate  these  possibilities.  Also  an  object  need  not  form 
views  in  every  context.  (For  example,  "Bill"  in  "reality"  in  the 
universal  context  is  a  view  in  Figure  1  but  "Bill"  in  the 
universal  context  is  not.)  If  an  object  does  not  form  a  view  in 
a  context  then  it  cannot  be  referenced  in  that  context  and 
definitely  cannot  exist  in  that  context.  This  is,  of  course. 


unlabelled  double  arrows  represent  the  IS-A  relationship,  and 
labelled  single  arrows  represent  property  values  with  the  labels 
being  the  property  names.  Property  definitions  are  not  shown  in 
the  figures. 
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also  allowed  in  other  context  mechanisms. 

However,  there  is  no  prohibition  against  having  more  than 
cne  view  of  an  object  being  a  context.  This  situation  is 
illustrated  in  Figure  1  where  there  are  two  contexts  using  the 
object  "fairy  world".  The  context  "fairy  world"  in  "reality"  in 
the  universal  context  may  be  guite  different  from  the  context 
"fairy  world"  in  the  universal  context.  For  example,  instances 
of  "FAIRY"  in  "fairy  world"  in  the  universal  context  may  not.  be 
able  to  perform  magic  whereas  instances  of  "FAIRY"  in  "fairy 
world"  in  "reality"  in  the  universal  context  may.  This  shows  one 
additional  ability  of  this  approach  to  contexts  over  the  other, 
more  traditional  approaches  which  may  be  of  use  in  deductive 
mechanisms  or  natural  language  interfaces  that  consider  the 
different  views  of  an  object  as  being  related. 


4.  Inheritance  in  Contexts 

If  the  contexts  "fairy  world"  in  "reality"  in  the  universal 
context  and  "reality"  in  the  universal  context  were  part  of  a 
knowledge  base  they  would  contain  a  lot  of  information  not 
related  to  fairies  and  thus  the  two  contexts  would  have  many 

objects  and  much  information  in  common.  This  indicates  that  the 

former  context  should  inherit  this  shared  knowledge  from  the 
latter.  However,  not  all  the  objects  in  the  latter  would  be  in 

the  former  and  there  may  be  other  differences  between  the 

contexts  and  thus  this  inheritance  should  not  be  strict. 

To  facilitate  talking  about  the  inheritance  between  contexts 
in  PS N  a  context  hierarchy  exists  in  PSN.  This  hierarchy  is 
defined  by  the  following  rule:  If  a  view  of  an  object  in  a 
context  forms  another  context  then  its  parent  in  the  context 
hierarchy  is  the  context  in  which  it  is  seen.  Thus  the  parents 
of  "reality"  in  the  universal  context  and  of  "fairy  world"  in  the 
universal  context  are  both  the  universal  context.  Further,  the 
parent  of  "fairy  world"  in 


"fairy  world"  in  "reality"  in  the 
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universal  context  is  "fairy  world"  in  "reality"  in  the  universal 
cortext  and  its  parent  is  "reality"  in  the  universal  context. 
This  gives  rise  to  a  tree  hierarchy  where  inheritance  between 
contexts  goes  down  the  hierarchy  (similar  to  inheritance  between 
classes  down  the  IS-A  hierarchy) . 

This  inheritance  differs  from  inheritance  down  the  IS-A 
hierarchy  in  several  ways.  First,  the  things  inherited  are 
different.  Definitions  of  properties  and  values  of  properties 
are  inherited  down  the  IS-A  hierarchy  whereas  everything  in  PSN 
including  objects,  properties  of  objects,  and  definitions  of 
properties  for  objects  are  inherited  down  the  context  hierarchy. 
Second,  the  inheritance  down  the  IS-A  hierarchy  is  very  strict  in 
some  aspects:  as  far  as  definitions  of  properties  go  only 
additions  of  new  definitions  and  specializations  of  existing 
definitions  are  allowed  from  a  class  to  a  sub-class.  Inheritance 
down  the  context  hierarchy  is  not  nearly  so  strict  and  any  change 
can  be  made  between  a  context  and  its  children  in  the  context 
hierarchy. 

The  inheritance  proceeds  as  follows:  if  an  object  A  in 
context  c  is  a  view  and  if  B  in  c  is  a  context  then  A  in  B  in  c 
will  be  a  view  unless  explicitly  deleted  by  B  in  c.  The  same  is 
true  of  A  being  an  instance  of  a  class  in  c.  The  properties  of  A 
in  B  in  c  are  defined,  as  before,  to  be  those  properties  defined 
in  the  classes  of  which  A  in  B  in  c  is  an  instance  and  the 
property  values  for  these  properties  are  inherited  in  the  same 
fashion  as  views  and  instances  except  that  properties  are  single 
valued  so  any  new  value  for  a  property  will  override  the 
inherited  one. 

For  example,  if  "John"  in  the  universal  context  is  a  view 
and  "fairy  world"  in  the  universal  context  is  a  context  then  by 
context  inheritance  "John"  in  "fairy  world"  in  the  universal 
context  is  a  view.  However,  this  may  be  overridden  so  that 
"John"  in  "fairy  world"  in  the  universal  context  is  not  a  view. 
Further,  even  if  it  is  a  view  then  "John"  could  be  an  instance  of 
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a  different  class  in  the  two  contexts,  perhaps  "PERSON”  in  one 
context  and  "FAIRY"  in  the  other  (as  in  Figure  2)  .  Here  it  is 
net  necessary  for  "FAIRY"  to  be  an  IS-A  descendant  of  "PERSON"  as 
would  be  the  case  with  IS~A  inheritance.  Other  properties 
associated  with  "John"  may  change  between  the  two  contexts,  such 
as  " J ohn " ' s  "height",  and  some  may  in  fact  disappear  or  appear, 
such  as  "John"*  s  "tribe",  if  the  sets  of  properties  defined  in 
"PERSON"  and  "FAIRY"  are  different.  Note  that  "John" 's  "age"  is 
net  changed  in  "fairy  world"  in  the  universal  context  and  thus 
will  be  inherited  from  the  universal  context.  Of  course  this  is 
not  much  different  from  other  context  schemes  such  as  Hendrix's 


INTELLIGENT  BEING 

life 

PERSON - - >70 

a  expectency 


Ficrure  2 
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[Hendrix  1  979  ]  or  Fahlman^s  [ Fahlman  1979  ], 

The  situation  is  more  complicated  for  classes  because  of  the 
interaction  with  IS-A  inheritance.  Views  of  classes  and  the  IS-A 
relationship  are  inherited  in  the  same  fashion  as  views  of  normal 
objects  and  the  instance  relationship.  The  same  is  true  for 
properties  of  classes  but  for  property  values  there  are  two 
possible  places  to  inherit  from,  the  IS-A  parents  in  the  same 
context  and  the  view  of  the  class  in  the  parent  context.  The 
solution  adopted  is  to  inherit  from  the  parent  context  if 
possible,  and  only  if  this  fails  to  produce  a  value  inherit  from 
the  IS-A  parents.  This  reflects  the  opinion  that  different  views 
of  an  object  are  more  likely  to  have  the  same  property  values 
than  a  class  and  its  parents  in  the  IS-A  hierarchy.  This 
situation  is  illustrated  in  Figure  2  where  the  ‘'life  expectancy" 
for  "PERSON"  in  "fairy  world"  in  the  universal  context  is 
inherited  from  "PERSON"  in  the  universal  context  and  not  from 
"INTELLIGENT  BEING"  in  "fairy  world"  in  the  universal  context. 

Property  definitions  have  the  same  problem  of  where  to  look 
in  inheritance  with  the  extra  added  problem  of  the  strictness  of 
IS-A  inheritance  of  property  definitions.  The  solution  is  to 
inherit  as  follows:  First  inherit  the  property  definitions  from 
the  IS-A  parents.  Then  if  there  are  changes  to  the  property 
definitions  in  the  view  of  the  class  in  the  parent  context,  they 
will  modify,  but  only  to  specialize,  the  IS-A  inherited  property 
definitions.  Any  modifications  that  would  violate  the  IS-A 
inheritance  rules  are  not  carried  out.  Finally  any  modifications 
in  the  class  itself  serve  to  override  the  modifications  inherited 
from  the  parent  context  as  long  as  they  do  not  violate  the  IS-A 
inheritance  rules.  If  there  are  property  definitions  introduced 
in  the  view  in  the  parent  context  that  are  not  in  the  IS-A 
parents  then  these  are  inherited  and  can  be  changed  in  the  class 
itself.  These  inheritance  rules  serve  to  retain  the  strict  IS-A 
inheritance  of  property  definitions  while  allowing  non-strict 
inheritance  down  the  context  hierarchy.  Again,  this  is  not  much 
different  from  other  context  mechanisms,  at  least  as  far  as  the 
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context  inheritance  goes. 


5.  Inheritance  of  Contexts 

The  new  aspects  of  this  approach  surface  if  different  views 
of  contexts  and  inheritance  of  contexts  down  the  context 
hierarchy  are  considered.  In  other  context  mechanisms,  contexts 
are  second  class  citizens  because  they,  as  opposed  to  regular 
objects,  do  not  exist  as  seen  in  a  context.  Thus  they  cannot 
have  different  views  and  cannot  be  inherited  between  contexts. 

The  context  mechanism  in  PSN  allows  both  of  these 
situations.  For  example,  consider  the  context  ’’fairy  world"  in 
the  universal  context  as  shown  in  Figure  2.  Objects,  such  as 
"John",  can  form  views  in  this  context.  However,  "fairy  world" 
is  an  object  and  so  it  too  can  form  a  view  in  the  context  "fairy 
world"  in  the  universal  context,  namely  the  context  "fairy  world" 
in  "fairy  world"  in  the  universal  context.  This  cannot  be  done 
in  other  context  mechanisms  and  the  advantage  to  doing  this  is 
that  there  may  well  be  properties  attached  to  "fairy  world"  in 
the  universal  context  such  as  cautions  that  unusual  things  may 
occur  in  it  and  these  properties  will  be  inherited  by  "fairy 
world"  in  "fairy  world"  in  the  universal  context  although  as  with 
all  context  inheritance  this  may  be  overridden.  Further,  these 
two  contexts  are  different  views  of  the  same  object  and  this  may 
be  of  use  to  deduction  mechanisms  and  natural  language 
interface  s. 

Note  that  context  inheritance  would  also  create  the  context 
"fairy  world"  in  "fairy  world"  in  "fairy  world"  in  the  universal 
context  and  then  go  on  ever  deeper  ad  infinitum.  This  infinite 
regression  of  contexts  is  not  really  a  problem  since  at  some 
point  they  will  cease  to  be  of  interest  and  so  they  need  not  be 
explicitly  stored.  If  at  any  time  more  become  of  interest  then 
they  will  be  available  automatically.  However,  this  infinite 
regression  does  preclude  calculating  all  inheritance  beforehand 
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(which  is  not  a  good  idea  in  any  case). 

Another  advantage  of  this  approach  to  contexts  is 
illustrated  in  Figure  3  where  one  of  the  views  shown  represents 
"FAIRY"  in  "fairy  world"  in  "John's  beliefs"  in  the  universal 
context.  In  this  figure  there  are  three  views  of  the  object 
"fairy  world",  namely  "fairy  world"  in  the  universal  context, 
"fairy  world"  in  "John's  beliefs"  in  the  universal  context,  and 
"fairy  world"  in  "Bill's  beliefs"  in  the  universal  context  and 
all  three  of  these  views  are,  in  fact,  contexts.  Now,  the  last 
two  of  these  inherit  from  the  first  because  properties  of  objects 
including  the  views  in  a  context  are  inherited  down  the  context 
hierarchy  (from  the  universal  context  to  "John's  beliefs"  in  the 
universal  context  and  "Bill's  beliefs"  in  the  universal  context). 
Thus  the  two  lower  (in  the  diagram)  views  of  the  object  "FAIRY" 
are  inherited  from  the  upper  view  and  unless  explicit  changes  are 
made  will  have  the  same  properties  as  the  upper  view. 


fairy  world 


FAIRY 


John's  beliefs  Bill's  beliefs 


fairy  world 

fairy  world 

FAIRY 

•  •  •  • 

FAIRY 

•  •  •  • 

Figure  3 
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Even  if  explicit  changes  are  made  to  the  lower  views  they 
will  inherit  the  unchanged  information  from  the  upper  view  and 
will  be  generally  the  same  as  the  other  lower  view  (unless 
massive  changes  are  made) .  This  cannot  be  done  by  using  a 
context  that  is  a  sub-context  of  both  "John's  beliefs"  and 
"Eill's  beliefs"  since  the  sub-context  method  can  only  represent 
situations  where  some  knowledge  is  exactly  the  same  in  two 
contexts. 

This  inheritance  of  contexts  does  cause  some  complications 
to  context  inheritance  because  it  introduces  more  than  one 
context  that  can  be  inherited  from.  The  context  "fairy  world"  in 
"John’s  beliefs"  in  the  universal  context  can  inherit  views  and 
other  information  from  "John's  beliefs"  in  the  universal  context 
(its  parent  in  the  context  hierarchy)  and  also  from  "fairy  world" 
in  the  universal  context  (a  slightly  less  involved  view  of 
itself)  .  Both  of  these  are  reasonable  sources  for  inheritance. 
The  solution  is  to  inherit  information  from  both  places.  This 
causes  problems  if  the  two  sources  are  contradictory,  such  as  two 
different  values  for  a  property,  and  in  these  cases  no 
information  would  be  inherited.  The  actual  resolution  of  these 
problems  is  tedious  because  of  the  many  cases  and  will  not  be 
discussed  here.  Note,  however,  that  the  simple  presence  of 
information  versus  its  absence  is  not  a  problem  because  the 
information  will  simply  be  inherited  from  where  it  is  present. 
This  more  complicated  inheritance  mechanism  still  retains  the 
non-strict  nature  of  context  inheritance  by  allowing  all  context 
inherited  information  to  be  overridden  while  also  retaining  the 
IS-A  inheritance  restrictions. 

6.  Conclusion 

The  main  contribution  of  contexts  in  PSN  is  the  formation  of 
the  context  hierarchy  which  provides  a  fourth  organizational 
principle  for  structuring  knowledge  in  PSN.  Unfortunately, 
contexts  and  the  context  hierarchy  have  been  less  understood  than 
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they  should  have  been.  The  discussion  in  this  paper  of  some  of 
the  aspects  of  the  formal  definition  of  PSN  contexts  given  in 
[Schneider  19*79]  will  help  to  alleviate  this  problem. 

The  most  significant  aspects  of  the  treatment  of  contexts 
proposed  here  are  the  additional  possibilities  inherent  in  it 
over  more  traditional  treatments.  These  come  about  because 
contexts  are  not  second  class  citizens  in  PSN.  Instead,  they  are 
formed  from  objects  just  like  any  other  view  in  a  PSN  knowledge 
base.  Thus  they  are  instances  of  classes  (in  fact  they  are 
defined  as  the  instances  of  the  class  "CONTEXT")  and  can  have 
properties  and  participate  in  relationships  just  like  other  views 
in  PSN.  This  is  achieved  in  other  systems,  if  at  all,  by  extra 
machinery,  such  as  associating  contexts  with  super-nodes  (as  in 
Hendrix’s  Partitioned  Networks  [Hendrix  1979  ]). 

Also  the  objects  which  form  contexts  may  form  different 
views  each  of  which  may  be  a  context.  These  different  contexts 
are  still  views  of  the  same  object  just  as  a  regular  object  may 
have  several  different  views.  This  allows  contexts,  along  with 
regular  views,  to  be  inherited  down  the  context  hierarchy.  This 
inheritance,  although  it  causes  some  complications  in  inheritance 
between  contexts,  allows  large  chunks  of  knowledge  to  be 
inherited  and  shared  between  contexts  with  modifications  to 
portions  of  it  still  possible  while  retaining  its  ability  to  be 
referenced  as  an  entity,  something  no  other  context  formulation 
allows . 

There  is  still  work  remaining  to  be  done  on  contexts  in  PSN. 
Their  formal  definition  does  not  take  into  account  the  procedural 
aspects  of  PSN  and  needs  to  be  extended  in  this  direction 
hopefully  leading  to  a  complete  formal  definition  of  PSN.  Also, 
contexts  should  be  integrated  into  the  existing  implementation  of 
PSN  at  the  University  of  Toronto  (as  described  in  [Kramer  193  0  ]). 
However,  even  with  these  shortcomings  contexts  have  much  to  add 
to  PSN. 
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PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1978 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis,  EE,  August  1978] 

CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 
TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

[M.Sc.  Thesis,  CSRG,  October  1978] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  1.  Vanek,  February  1979 

CSRG-100  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 

CSRG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.),  May  1979 

CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.R.  Hehner,  May  1979 

CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-1 04  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  Juty  1979 

CSRG-1 05  A  LANGUAGE  FACILITY  FOR  DESIGNING  INTERACTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos,  Philip  A.  Bernstein,  Harry  K.T.  Wong, 
July  1979 

CSRG-1 06  ON  APPROXIMATE  SOLUTION  TECHNIQUES  FOR 

QUEUEING  NETWORK  MODELS  OF  COMPUTER  SYSTEMS 
Satish  Kumar  Tripathi,  July  1979 

CSRG-1 07  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  K.  Tsotsos,  John  Mylopoulos,  H.  Dominic  Cowey 
Steven  Yf.  Zucker,  DCS,  June  1979 

CSRG-1 08  DIALOGUE  ORGANIZATION  AND  STRUCTURE  FOR 
INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thesis,  DCS,  1980] 

CSRG-1 09  A  UNIFYING  MODEL  OF  PHYSICAL  DATABASES 
D.S.  Batory,  C.C.  Gotlieb,  April  1980 

CSRG-1 10  OPTIMAL  FILE  DESIGNS  AND  REORGANIZATION  POINTS 
D.S.  Batory,  April  1980 

CSRG-1 11  A  PANACHE  OF  DBMS  IDEAS  III 
D.  Tsichritzis  (ed.),  April  1980 
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CSRG-112  TOPICS  IN  PSN  -  II:  EXCEPTIONAL  CONDITION 

HANDLING  IN  PSN;  REPRESENTING  PROGRAMS  IN  PSN; 
CONTENTS  IN  PSN 

Yves  Lesperance,  Byran  M.  Kramer,  Peter  F.  Schneider 
April,  1980 


